home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 771 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.9 KB
  1. From: bernard@labri.u-bordeaux.fr (BERNARD Sebastien [93-94])
  2. Subject: Questions about memory and library
  3. Date: Tue, 11 Jan 1994 14:41:02 +0100 (MET)
  4. Mime-Version: 1.0
  5.  
  6.     Hello from france,
  7.   I'am a mint user since a few years now (from the 0.6 version precisely) and
  8. now  I'm a bit disappointed with MiNT for the following reasons :
  9.   - I started working on it with a 4MB STE but it was slow and lacking of memory.
  10.     so I went on a Falcon (8 months ago). It was faster but with still 4MB of
  11.     memory. But it's still short of memory. Unable to compile anything with
  12.     GNU and miniwin on desktop but little toys (files less than 60Kb) without
  13.     running anything with. Using OUTSIDE make the Falcon crash after the memory
  14.     has gone short.
  15.  
  16.   - So I ask myself, about three points that could be done :
  17.      1- virtual memory :
  18.        Looking the source of MiNT 1.09 allow me to think that everything is rea-
  19.        dy for this but the code ( there is even an empty function - init_swap -
  20.        for initialising the swap device ). It seems that virtual memory has been
  21.        voluntary stopped at the memory protection. Is it interesting for anybody
  22.        to develop virtual memory ? I am insteresting in it. But, maybe is there
  23.        some development running ? Please, let me know.
  24.  
  25.      2- shared memory :
  26.        For solving probkems due to lack of memory, a good solution could be the
  27.        sharing of memory for libraries so we don't have to duplicate the code
  28.        in the memory just the instance of variables. For this - it joins the
  29.        first point - we have to extend the MiNT kernel : add the possibility of
  30.        sharing pages of memory for root's process - or others' - .
  31.        This could creates some problems with executables that could absolutely
  32.        not be run under normal TOS ( but who wants downard compatibility ).
  33.        This will be very helpfull for make compilations in severals directory
  34.        where you can find up to 10 shells and 5 make running. We can make this
  35.        by improving the memory protection. Every process could start to the
  36.        same adresse ( relocation is no more needed ). The problem is that it 
  37.        could not be done for the 68000 machines ( only MMU machines ).
  38.        This leads me to the third points :
  39.  
  40.      3- a new executable format :
  41.        For differenciating shared executables and normal executables, it could
  42.        interesting to use a different binary format. I wish to use a standard
  43.        format to simplify the porting of GNU software and getting fully funtionnal
  44.        ports ( dump of emacs directly usable - straight port of GDB ). For this
  45.        should we modify the Pexec call to allow the execution of new binary format
  46.        and on the fly the working shell hack "#!/bin/sh" directly implemented.
  47.  
  48.   This is what I'd loved to see inside MiNT and the MiNTLIB. I wish I do it but
  49. I don't know 680x0'asm. I'm not fluent in MiNT but I could try. If anybody is
  50. interested, let me know.
  51.  
  52.   S. Bernard
  53.